A computer network is a geographically distributed collection of interconnected subnetworks for transporting data between nodes, such as computers. A local area network (LAN) is an example of such a subnetwork; a plurality of LANs may be further interconnected by an intermediate network node, such as a router or switch, to extend the effective “size” of the computer network and increase the number of communicating nodes. The nodes typically communicate by exchanging discrete frames or packets of data according to predefined protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other.
A communication session may be established between a source node and a destination node, each interconnected to an intermediate node by, e.g., a point-to-point link, shared LAN, wide area network (WAN) or virtual private network (VPN) implemented over a public network such as the Internet. Broadly stated, the session undergoes three distinct phases: session establishment, data transfer and session termination. During session establishment, the source node generally contacts a protocol-specific interface of the intermediate node, and the intermediate node establishes a protocol-specific path or “virtual circuit” between the source and destination nodes. For example, a source node connected to the intermediate node by a point-to-point link may initiate a Point-to-Point Protocol (PPP) session with a destination node. Once the connection has been established, data is transferred sequentially over the established path. When the session is no longer needed, the path is terminated.
One or more authentication processes are often implemented at session establishment time. For instance, an intermediate node may not permit the creation of a new PPP session unless a third party authentication service, such as a Remote Authentication Dial-in User Service (RADIUS), authenticates the source and/or destination nodes using, e.g., a Challenge Handshake Authentication Protocol (CHAP). The intermediate node may also rely on other authentication, authorization and accounting services of the RADIUS server when determining whether to accept or reject a new session. The operations of a RADIUS server are more fully described in RFC 2865 entitled Remote Authentication Dial In User Service (RADIUS), which is hereby incorporated by reference as though fully set forth herein.
In general, to initiate a new session, a source node first sends one or more protocol data units (PDU) to an interface of the intermediate node. The PDUs may include, inter alia, control parameters for the session, such as a network address of a destination node, a frame encapsulation format, the source node's authentication information, etc. The intermediate node then configures the communication session in accordance with these control parameters. More specifically, depending on the type of session protocol, i.e., Point-to-Point Protocol over Ethernet (PPPoE) or Layer-2 Tunnel Protocol (L2TP), the intermediate node may process different PDU formats and contact one or more third party services, such as RADIUS.
For example, a source node attempting to establish a PPPoE session first sends an intermediate node an “initiation” PDU, commonly known as a PPPoE Active Discovery Initiation (PADI). Upon receiving the PADI, the intermediate node sets up the PPPoE session by participating in a multi-step PDU exchange that may involve receiving an additional PPPoE Active Discovery Request (PADR) packet from the source node, as described more fully in RFC 2516 entitled A Method for Transmitting PPP over Ethernet (PPPoE), which is hereby incorporated by reference as though fully set forth herein. In contrast, a source node establishing an L2TP session initially sends the intermediate node a PDU having a different format, conventionally known as an Incoming Call Request (ICRQ). In this case, the intermediate node is engaged in a different PDU message exchange process, as described in more detail in RFC 2661 entitled Layer Two Tunneling Protocol “L2TP, ” which is also hereby incorporated by reference as though fully set forth herein.
An intermediate node, i.e., a switch or router, may service tens of thousands of communication sessions at once. Typically, in “steady-state” operation, not every session is actively exchanging information at the same time, so the node's resources, such as central processing unit (CPU) bandwidth and available memory, are not overly consumed by the sessions. However, in the event of a temporary network outage to the intermediate node, such as a power outage or “line flap,” the tens of thousands of sessions will typically be simultaneously disconnected. Consequently, the intermediate node may not have the available resources to re-establish all the disconnected sessions at substantially the same time.
For example, to reestablish sessions requiring RADIUS authentication, the intermediate node may have to buffer one or more PDUs, i.e., RADIUS, PADI, PADR and ICRQ packets, until the RADIUS server confirms or rejects authentication of a source and/or destination node. Thus, when the intermediate node is “flooded” by new session establishment attempts, the node may not have sufficient memory resources to store all the received PDUs while waiting for corresponding RADIUS server responses. Furthermore, in this situation, the CPU bandwidth of the intermediate node may not be sufficient to simultaneously process the thousands of received PDUs.
Previously, when an intermediate node receives more session establishment requests than its resources can manage, the node still attempts to establish a session for each received PDU. Clearly, this can result in excessive session establishment latencies if not outright session count oscillation. Further, additional delays may be created by a third party authentication service, such as RADIUS, that participates in the session establishment procedure. That is, even if the intermediate node has the resources to establish all the new sessions, the third party service may not. Thus, because an intermediate node or third party service may experience excessive delays while setting up a plurality of sessions, source nodes may “timeout” while waiting for a response to its initial PDU, i.e., a PADI or ICRQ packet, and may subsequently reattempt to establish the session after a predetermined time interval. In this manner, some source nodes timeout and send new PDUs even while the intermediate node continues to consume resources processing their previously sent PDUs.
The present invention is directed toward implementing call admission control (CAC) at a network node, such as an intermediate node. As used herein, call admission is the process of establishing communication sessions between network nodes. Accordingly, while previous CAC techniques allowed a plurality of new session establishment attempts to rate-limit themselves, i.e., by allowing source nodes to continually timeout and retry until their session is established, the invention implements a call admission technique that more efficiently utilizes a network node's resources, thereby decreasing its latency of establishing a large number of new communication sessions.